Some key practices used to implement a new development environment, consisting of the Rational Unified Process together with tools, are:

Assess the Project and the Organization To top of page

Assess the current state of the project and the organization to better understand what parts of the environment you should improve. You will also better understand how to implement the environment. 

The following pages explain how to assess the state of a project and its surrounding organization:

Implement Process and Tools Incrementally To top of page

Implement the environment, process, and tools incrementally so people on the projects won't be overwhelmed by many new factors all at once. By implementing the environment incrementally, it's possible to focus on a subset of the environment, which increases the probability of success. 

Introduce the environment one piece at a time. The result of the development organization assessment helps decide which parts of the process and which tools you should start to introduce. Normally, focus on those areas where the development organization has its biggest problems. 

Incrementally implementing the environment might mean that in a first, or inception, iteration, you focus on introducing the Requirements workflow together with the Requirements tools. In the second iteration, the focus is on introducing the Analysis & Design workflow together with its modeling tools. In subsequent iterations, more and more parts of  the environment are introduced.

See Concepts: Implementing a Process in a Project for details. 

Manage and Plan To top of page

Manage and plan the environment activities just as you would with all other activities in the software development project. 

Implementing a new process and new tools on a project is a complex task. Changing the way people work can jeopardize the success of a project. Experience shows that when compared to the development activities, the environment activities are sometimes overlooked by the project manager. 

The environment activities must be managed and planned like all other activities in a software development project. Therefore, it's important that the project manager has a good understanding of the new process and tools. Sometimes it's difficult for the project manager to allocate the necessary time to learn about both a new process and potentially several new tools. In that case, the project manager needs support from someone who knows both how to implement the environment and who has previously been involved in doing so. Even if the project manager has the right set of skills and experience, we recommend that you involve "environment-implementation expertise", as it greatly increases the chances for the project to succeed.

See the Project Management workflow for details on how to manage and plan a software development project, including the environment activities. Also see Concepts: Implementing a Process in a Project. 

Use Mentors To top of page

Use mentors to introduce a new process in a project. Experience shows that using mentors is crucial if you want the implementation of a new process to succeed. If you don't have mentors, there's a clear risk that the people on the project will fall back into their old habits. The mentor acts as a driver of change. 

The project needs both the resources and the budget for mentoring on the project. The occurrence of some mentoring activities need to be planned, such as leading workshops. It's important that the process mentor understands the role of being a change driver and makes sure that the work progresses. It's also important that the mentor becomes dispensable and that there is an end to it, therefore, the mentor needs to transfer both knowledge and responsibilities to members of the project. See Concepts: Mentoring for more details on what a mentor is and what a mentor does.

Distribute Process Ownership To top of page

Distribute the ownership for the process among the people on the project because they're more likely to adopt and learn the new process faster. The resulting development case is better when the "real experts", those people on the project, develop it themselves. If you distribute the ownership for the process, it will also reduce the likelihood of the project becoming too heavily dependent on outside consultants. 

As soon as possible appoint people on the project to be responsible for each core process workflow. This person has primary responsibility for configuring that part of the process and the corresponding part of the development case. For example, being responsible for a core process workflow like requirements, means you're responsible for that part of the development case. Each person needs to be responsible for one or several core process workflows, and is someone who knows the area well and who can mentor other developers.  

A process engineer acts as mentor to the people on the project who own the different parts of the process and assists them when they configure the process. 

Think 'Return-On-Investment' To top of page

Think 'return-on-investment' when you configure the process: focus on those things that will pay back more than the investment. 

Experience shows that some projects tend to spend too much time and resources developing extensive guidelines, an extensive development case, and additional process- related material. There are three major problems with this:

  • People do not read extensive descriptions. 
  • Doing everything right from the beginning is very difficult. It's better to do something less extensive, try it out, and then adjust it. 
  • It removes the focus from mentoring. People with process knowledge need to have mentoring, not writing extensive descriptions, assigned as their primary task. 

When developing guidelines, you need to keep in mind the return-on-investment. Try to reuse existing guidelines. For example, a cost-efficient alternative to developing a complete use-case modeling guideline is to let a good example of an existing use-case description serve as the Use-Case Modeling Guidelines.  

In practice, you can't measure the investment and the pay-back, then compare the two. As a process engineer, the most important thing to always keep in mind is that whatever you do, it must have a substantial pay back for the developers.

Keep People Informed and Involved To top of page

Keep people informed about the new process and tools, and have them involved in the work because the greatest threat to any change in an organization is peoples' attitudes towards the change. Introducing a new process and tools in any organization means that people have to change the way they work. People have a natural resistance toward change. There's always the risk of falling into a negative spiral, where people's negative attitudes lead to poorer results which then lead to even more negative attitudes.

The following lists some actions you can take that may help prevent negative attitudes from forming among people in the organization: 

  • Set realistic expectations. Do not oversell the new process or the new tools. 
  • Involve key people in the change work. Let them be part of the pilot project and give them responsibility for parts of the process. See Distribute Process Ownership.
  • Explain why the change needs to be done. What problems does the organization have that need to be solved? What changes in technology require a new process and new tools? How will you benefit from using these new tools and process?
  • Inform all people in the organization about what is happening. For example, keep all departments informed about what is going on. This information doesn't have to be in very great detail; the important thing is that they receive some information.   
  • Remember stakeholders, such as customers or sponsors. For example, if you change from a more waterfall-like development approach to an iterative development approach, the stakeholders must understand how an iterative development project is managed and how progress is measured. In an iterative development project, for example, they can't expect a completely frozen design at an early milestone. They would also be affected when projects change the way they capture requirements. 

Educate People To top of page

Educate people about the new process and the new tools because they need to understand both the new process and how to use the new tools. 

There are several ways to educate people, including the following methods that have been used:

  • Standard training courses
  • "Boot-camps" consisting of 1 to 5 weeks of concentrated, hands-on training. Not many organizations can afford boot-camps, however, they have proven to be efficient if there are many new factors for the people in the project. 
  • Mentoring works when you have a mentor who reviews results, leads workshops, and answers questions. Done well, mentoring can be a very efficient way to transfer knowledge.
  • "Kick-start" workshops are an efficient way to get the people up-to-speed in a day when introducing a new part of the environment. In this type of workshop, people work using their real project material and following the new parts of the development case using the new templates, guidelines, and tools. Typically, a process engineer and a tool specialist would be responsible for this workshop. Do not spend a lot of time developing training material for a kick-start workshop. The main purpose is to give hands-on experience using new sections of the development case together with templates, guidelines, and tools. The kick-start workshop is also a way to verify the development case, templates, guidelines, and tools. 
Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Display Rational Unified Process using frames

Rational Unified Process